Packets of data in a computer network typically contain information stored in protocol header fields corresponding to the various protocols that form the protocol stack for that packet. A protocol stack is a set of network protocols that work together so that two or more computers or other devices can communicate across a network. The different protocols that form a protocol stack frequently occupy different “layers” in the Open System Interconnection (OSI) Model. A commonly used protocol stack consists of the HyperText Transfer Protocol (HTTP), Transmission Control Protocol (TCP), Internet Protocol (IP) and Ethernet Protocol.
A network device will typically comprise a network processor operative to determine which operations to perform on a packet of data by addressing one or more lookup tables with the contents of some subset of the protocol header fields contained in that packet. The particular protocol header fields that form this subset vary with the network environment and with the network device user. For example, a specific user may wish that a network device examine fields in the Asynchronous Transfer Mode (ATM) Protocol, TCP, IP and Ethernet protocol header fields to determine how to properly forward the packet to the next network device. A different user may wish to examine an entirely different set of protocol header fields. As a result, it is frequently desirable to tailor the network device to match the user's specific application.
Notwithstanding this, such user-specific programming remains problematic. For example, programming network device software specifically for a network device user's particular application may be expensive. Moreover, such user-specific programming lacks flexibility since the protocol header fields to be examined are fixed at the time the device software is written. As a result, most device manufacturers supply the same software to multiple users rather than attempt customization. This multi-user software will examine the union of what individual users may be interested in examining rather than addressing the particular needs of the specific user. Consequently, this software may examine many protocol header fields that are not of interest to a particular user while skipping over those that are of interest. This compromises performance and can increase the overhead of provisioning lookup table data since a user may need to provision data for protocol header fields that the user has little or no interest in examining.
For these reasons, there is a need for a network device that can be easily and cost-effectively tailored to examine only those protocol header fields relevant to a particular user's specific network application.